But first, let me say that I hate Microsoft as much as he seems to; really truly I do, for all their evil business practices and the narrow-mindedness of their ‘community’.

BUT….

The one thing they have one right is the concept of intallers. They have created both the expectation and the possibility that someone can install something without having to endlessly twiddle stuff, and it just works at that point.

Never mind that most of their products are mediocre. Bear in mind that the mediocrity is often related to too much complexity and dependencies, but still they have managed to promulgate and realize the idea that things can be installed without requiring deep knowledge of internals.

This is as it should be.

Those who apparently pride themselves on their ability to navigate the arcana of installing Linux and Linux apps completely miss the point. Btw, I have been programming for 40 years on everything from IBM 360 assebmler to Java and PHP and a lot inbetween, including Unix device drivers. But I don’t measure my self worth based on knowing some minutia that will change tomorrow.

Ian has the right attitude: the Linux community needs to get this right if it wants to see mainstread adoption.

I’ve updated the page – thanks. I assumed it needed root because it asks for the root password when you run the installation script, but of course there’s no real reason why that should be necessary.

The klik web service (just like most web services) isn’t decentralized yet, but of course everyone can make his/her private cmg files available.

Also, a non-root user can unpack a cmg file, and hence can use klik without ever being root (no fstab entries or other tricks required for unpacking a cmg

The Zero Install web-site says for Klik:

Users can install software: Yes

Non-root install of system: No

This agrees with what you said, no?

Presumably fuse, plash and/or ROX application directories could remove this limitation of Klik.

However, Klik isn’t decentralised (there can’t be two different klik packages in the world both called ‘convert’ for example, and if the central server is down then nothing can be installed anywhere in the world).

That said, there are ways to make it better. If you want to see how smooth it SHOULD be for an end user to install software on Linux (commercial or open source), take a look at what My Game Company did with the Linux installer for their recent commercial game “Dirk Dashing: Secret Agent”. It uses Bitrock, along with some custom scripts for installing menu items into the System menu on LSB-compliant distros. You can install their game as root or as a regular user. There’s even an uninstaller. I’ve been able to successfully install this game on SUSE, Fedora, Ubuntu, Linspire, and Debian. From the Bitrock web site, Bitrock appears to be an ideal solution for both commercial and open source projects.

You can download the Dirk Dashing demo from http://www.dirkdashing.com – click on the Try It button, select the Linux version, and follow the install instructions. Beautiful!

Right, I agree. Except that this is not quite “another” approach from what above mentioned klik does. It is, in essence, the same — with an additional twist: instead of putting “everything in one single AppDir directory”, klik puts “everything into one single file”. [Where the single file typically is a cramfs-compressed archive of the mentioned AppDir…]

This approach gains several additional benefits over simple AppDirs:

Saves space. Typically you’d need 35 harddisk units instead of 100. (And doesn’t cost any noticeable CPU overhead to uncompress into RAM for running it…)
Makes relocation to different medium more easy, and faster. (Copy only a single file.)
Makes removal of the application more easy, and faster (Delete only a single file.)
Preserves compatibility to the AppDir. (Expand the klik cramfs and you get… a compliant AppDir.)